Overview of IEEE software project management plan (SPMP)
Source: Object Oriented & Classical Software Engineering, 7th edition, Stephen R. Schach, pg. 270 273
1 Overview
1.1 Project Summary
1.1.1 Purpose, scope, and objectives
Detta projekt går ut på att skapa ett e-commerce system som erbjuder allt en butik kan behöva. Detta innebär lager hantering, kundregister och ett system som hanterar faktureringar. Systemet skall kunna ha skillnad på olika kundgrupper, t.ex. andra cykelaffärer och företagets anställda skall kunna beställa med -15% rabatt. En specialiserad modul för att sköta reparationer ska också skapas. Hela systemet ska vara webbaserat och enligt klient-server arkitektur. Ingen installation på TopBikes egna datorer utan allt styrs över internet.
1.1.2 Assumptions and constraints
Projektet måste vara klar i tid, och inom avtalad budget. Systemet skall vara pålitligt och användarvänligt. Det måste också vara väldokumenterat och möjliggöra eventuella utvidgningar i senare skeden
1.1.3 Project deliverables
e-commerce system, med lagerhantering och ett system som handhar fakturering som automatiskt kollar referensnumret på inkomna betalningar. Användarmanualen kommer med systemet och skolning för hela personalen ges vid ibruktagandet. En uppföljning görs en gång i månaden dom tre första månaderna för att se till att kunden kan använda systemet.
1.1.4 Schedule and budget summary
Årlig avgift på systemet 15000£
Reparations modul: 5000£
Hårdvaruinvesteringar: 10000£
Huvud modulen klar 1 april 2011, reparationsmodulen förväntas bli klar 1 juni 2011.
1.2 Evolution of the project management plan
2 Reference materials
3 Definitions and acronyms
4 Project organization
4.1 External interfaces - Projektledaren är ansvarig för kundkontakten och kontakten med företagsledningen, medan projektets testansvariga är ansvarig för kontakten till hårdvaruavdelningen.
4.2 Internal structure - Projektgruppen består av en projektledare, tre programmerare och en testansvarig. Utanför själva projektgruppen ansvarar SMEsonline's hårdvaruavdelning för hårdvarulösningen och två programmerare fungerar som huvudsaklig rådgivande personal för projektgruppen.
4.3 Roles and responsibilities
Funktion
Ansvarig
Design av hela systemet
Projektledaren
Design av modifikationer
Projektledaren och den modifieringsansvariga programmeraren
Design av reparationsmodulen
De två utvecklingsansvariga programmerarna
Kvalitetshantering
Testansvarig
Dokumentation
Projektledaren övervakar att dokumentation sker enligt företagets dokumentationspraxis. Varje projektmedlem skriver sin egen dokumentation som sedan sammanställs till enhetliga dokument av integrationsansvarige.
Integration av systemet
Den modifieringsanvarige programmeraren
Kundkontakt
Projektledaren
Modifiering av systemet
En programmerare
Utveckling av reparationsmodulen
Två programmerare
Testning
Testansvarig är ansvarig för helheten, men varje programmerare är ansvarig för sin del av systemet
Hårdvara
Hårdvaruavdelningen samt internt testansvarig
5
Managerial process plans
5.1 Start up plan
5.1.1 Estimation plan
Som tidigare konstaterats så är kostnaderna 10000 för hårdvaro och 5000 för utveckling av en ny modul till systemet samt årliga kostnader på 15000.
5.1.2 Staffing plan
Projektledaren behövs för hela projektets längd.För planeringen av reparationsmodulen behövs de två utvecklingsansvariga programmerarna och för själva utvecklingen behövs två programmerare. För modifieringen och integreringen av reparationsmodulen behövs en programmerare, och för testningen ansvarar testansvarige.
5.1.3 Resource acquisition plan
5.1.4 Project staff training plan
5.2 Work plan
5.2.1 Work activities
5.2.2 Schedule allocation
07.3.2011 - Möte med kunden, evaluering av nuläge och kartläggning av behövlig data
15.3.2011 - Fastslagning av kundens specifika data
21.3.2011 - Installering av hårdvara hos kunden
28.3.2011 - Kunden kan logga in och kontrollera all initial data och kundspecifik information
30-31.3.2011 - skolning före ibruktagningen
01.4.2011 - Ibruktagning av grundsystemet
15.4.2011 - Telefonkontroll ifall allt fungerar som det borde, eller behövs det mera skolning
01.5.2011 - Reparationsmodulens planering och produktion börjar
01.6.2011 - Testandet av reparationsmodulen kan börja
01.7.2011 - ibruktagning av reparationsmodulen
5.2.3 Resource allocation
1) möte, bekantning med nuläget, initial plan, huvudflöden 2 dagar
2) initiell design, screenlayout av reparationsmodul, genomgång med kunden 3 dagar
3) jobb..... 4 veckor
4) intern testning och felsökning 1 dag
5) beta testning med kunden 3 veckor
6) korrigeringar av funna problem i punkt 6.
7) skolning och ibruktagning 1,5 dagar
5.2.4 Budget allocation
5.3 Control plan
Projektledaren är ansvarig för projektet som helhet samt kontrollen av utnyttjade resurser så att budgeten och tidtabellen håller. Projektledaren får information om använda timmar i projektet direkt från timuppföljningsprogrammet som alla anställda fyller i dagligen. Alla ändringar som orsakar ändringar i tidtabellen, resursbehoven eller i milstolparna skall godkännas av projektledaren.
Projektets framgång behandlas vid normala veckomöten och i dagsmöten med utvecklingsprogrammerarna endast när reparationsmodulen utvecklas. Alla projektmedlemmar är ansvariga för normal testning och kvaliteten av sitt eget arbete, utöver detta genomförs också testning av den nya modulen av de egna utvecklngsprogrammerarna samt någon från den egna personalen ur andra projekt.
När det gäller reparationsmodulen utförs tester också av kunden före ibruktagandet.
5.3.1 Requirements control plan
5.3.2 Schedule control plan
5.3.3 Budget control plan
5.3.4 Quality control plan
5.3.5 Reporting plan
5.3.6 Metrics collection plan
5.4 Risk management plan
Risk
Sannolikhet
Inverkan på projektets framgång
Åtgärder för att undvika risken
Projektet tar mer tid i anspråk än beräknat
50 %
Låg
Milstolpar och tidsövervakningssystem, samt planerad tidsreserv för överskridningar
Projektet överskrider budgeten
40 %
Medel
Noggrann planering och budgetuppföljning under projektets gång
Projektmedlemmar lämnar gruppen
25 %
Betydande
God dokumentation genom hela processen samt att det alltid finns flera personer med insikt om olika delar av projektet
Funktionaliteten motsvarar inte kundens förväntningar
20 %
Allvarlig
God planering, lättförståelig kommunikation och kunden i en central roll i utvecklingsprocessen
Nya anställda anpassar sig inte till företagets arbetsmetodik och typen av system
10 %
Betydande
Tillräcklig uppföljning, minst en erfaren programmerare inom projektgruppen samt ytterligare erfaren personal tillgänglig för rådgivning
Slutprodukten uppfyller inte pålitligthetskriterierna
5 %
Kritisk
Kontinuerlig testning och omfattande fullskalig testning före ibruktagandet samt utnyttjande av företagets beprövade utvecklingssätt för den här typen av system
Slutprodukten är inte tillräckligt användarvänlig
5 %
Allvarlig
Använder företagets beprövade gränsnitt samt tillåter olika kundrepresentanter att testa användargränssnittet i ett tidigt skede.
5.5 Project close out plan
Efter att den utvecklade reparationsmodulen är ibruktagen hos kunden så hålls ett slutmöte för projektet där det kontrolleras att utvecklingen av modulen gick enligt tidtabellen och att använda resurser inte överskred de som planerades för projektet. Möjliga problem och problemlösningar gås igenom. Reparationsmodulens användningsmöjligheter gås också igenom samt möjliga förslag för att förbättra/förenkla nyutveckling av nya moduler gås igenom.
6
Technical process plans
6.1 Process model - Projektet kommer att använda sig av rörliga metoder.
6.2 Methods, tools, and techniques
6.3 Infrastructure plan
6.4 Product acceptance plan
7
Supporting process plans
7.1 Configuration management plan
7.2 Testing plan
7.3 Documentation plan
7.4 Quality assurance plan
are encompassed by this section.
7.5 Reviews and audits plan
7.6 Problem resolution plan
7.7 Subcontractor management plan
7.8 Process improvement plan
Additional plans
Overview of IEEE software project management plan (SPMP)
Source: Object Oriented & Classical Software Engineering, 7th edition, Stephen R. Schach, pg. 270 273
1 Overview
1.1 Project Summary
1.1.1 Purpose, scope, and objectives
Detta projekt går ut på att skapa ett e-commerce system som erbjuder allt en butik kan behöva. Detta innebär lager hantering, kundregister och ett system som hanterar faktureringar. Systemet skall kunna ha skillnad på olika kundgrupper, t.ex. andra cykelaffärer och företagets anställda skall kunna beställa med -15% rabatt. En specialiserad modul för att sköta reparationer ska också skapas. Hela systemet ska vara webbaserat och enligt klient-server arkitektur. Ingen installation på TopBikes egna datorer utan allt styrs över internet.
1.1.2 Assumptions and constraints
Projektet måste vara klar i tid, och inom avtalad budget. Systemet skall vara pålitligt och användarvänligt. Det måste också vara väldokumenterat och möjliggöra eventuella utvidgningar i senare skeden
1.1.3 Project deliverables
e-commerce system, med lagerhantering och ett system som handhar fakturering som automatiskt kollar referensnumret på inkomna betalningar. Användarmanualen kommer med systemet och skolning för hela personalen ges vid ibruktagandet. En uppföljning görs en gång i månaden dom tre första månaderna för att se till att kunden kan använda systemet.
1.1.4 Schedule and budget summary
Årlig avgift på systemet 15000£
Reparations modul: 5000£
Hårdvaruinvesteringar: 10000£
Huvud modulen klar 1 april 2011, reparationsmodulen förväntas bli klar 1 juni 2011.
1.2 Evolution of the project management plan
2 Reference materials
3 Definitions and acronyms
4 Project organization
4.1 External interfaces - Projektledaren är ansvarig för kundkontakten och kontakten med företagsledningen, medan projektets testansvariga är ansvarig för kontakten till hårdvaruavdelningen.
4.2 Internal structure - Projektgruppen består av en projektledare, tre programmerare och en testansvarig. Utanför själva projektgruppen ansvarar SMEsonline's hårdvaruavdelning för hårdvarulösningen och två programmerare fungerar som huvudsaklig rådgivande personal för projektgruppen.
4.3 Roles and responsibilities
5
Managerial process plans
5.1 Start up plan
5.1.1 Estimation plan
Som tidigare konstaterats så är kostnaderna 10000 för hårdvaro och 5000 för utveckling av en ny modul till systemet samt årliga kostnader på 15000.
5.1.2 Staffing plan
Projektledaren behövs för hela projektets längd.För planeringen av reparationsmodulen behövs de två utvecklingsansvariga programmerarna och för själva utvecklingen behövs två programmerare. För modifieringen och integreringen av reparationsmodulen behövs en programmerare, och för testningen ansvarar testansvarige.
5.1.3 Resource acquisition plan
5.1.4 Project staff training plan
5.2 Work plan
5.2.1 Work activities
5.2.2 Schedule allocation
07.3.2011 - Möte med kunden, evaluering av nuläge och kartläggning av behövlig data
15.3.2011 - Fastslagning av kundens specifika data
21.3.2011 - Installering av hårdvara hos kunden
28.3.2011 - Kunden kan logga in och kontrollera all initial data och kundspecifik information
30-31.3.2011 - skolning före ibruktagningen
01.4.2011 - Ibruktagning av grundsystemet
15.4.2011 - Telefonkontroll ifall allt fungerar som det borde, eller behövs det mera skolning
01.5.2011 - Reparationsmodulens planering och produktion börjar
01.6.2011 - Testandet av reparationsmodulen kan börja
01.7.2011 - ibruktagning av reparationsmodulen
5.2.3 Resource allocation
1) möte, bekantning med nuläget, initial plan, huvudflöden 2 dagar
2) initiell design, screenlayout av reparationsmodul, genomgång med kunden 3 dagar
3) jobb..... 4 veckor
4) intern testning och felsökning 1 dag
5) beta testning med kunden 3 veckor
6) korrigeringar av funna problem i punkt 6.
7) skolning och ibruktagning 1,5 dagar
5.2.4 Budget allocation
5.3 Control plan
Projektledaren är ansvarig för projektet som helhet samt kontrollen av utnyttjade resurser så att budgeten och tidtabellen håller. Projektledaren får information om använda timmar i projektet direkt från timuppföljningsprogrammet som alla anställda fyller i dagligen. Alla ändringar som orsakar ändringar i tidtabellen, resursbehoven eller i milstolparna skall godkännas av projektledaren.
Projektets framgång behandlas vid normala veckomöten och i dagsmöten med utvecklingsprogrammerarna endast när reparationsmodulen utvecklas. Alla projektmedlemmar är ansvariga för normal testning och kvaliteten av sitt eget arbete, utöver detta genomförs också testning av den nya modulen av de egna utvecklngsprogrammerarna samt någon från den egna personalen ur andra projekt.
När det gäller reparationsmodulen utförs tester också av kunden före ibruktagandet.
5.3.1 Requirements control plan
5.3.2 Schedule control plan
5.3.3 Budget control plan
5.3.4 Quality control plan
5.3.5 Reporting plan
5.3.6 Metrics collection plan
5.4 Risk management plan
Efter att den utvecklade reparationsmodulen är ibruktagen hos kunden så hålls ett slutmöte för projektet där det kontrolleras att utvecklingen av modulen gick enligt tidtabellen och att använda resurser inte överskred de som planerades för projektet. Möjliga problem och problemlösningar gås igenom. Reparationsmodulens användningsmöjligheter gås också igenom samt möjliga förslag för att förbättra/förenkla nyutveckling av nya moduler gås igenom.
6
Technical process plans
6.1 Process model - Projektet kommer att använda sig av rörliga metoder.
6.2 Methods, tools, and techniques
6.3 Infrastructure plan
6.4 Product acceptance plan
7
Supporting process plans
7.1 Configuration management plan
7.2 Testing plan
7.3 Documentation plan
7.4 Quality assurance plan
are encompassed by this section.
7.5 Reviews and audits plan
7.6 Problem resolution plan
7.7 Subcontractor management plan
7.8 Process improvement plan
Additional plans